Linux-based Operating Systems (OS) are growing and evolving at a very rapid pace. Such development places a burden on device driver developers who must keep pace with the growth. In contrast to the application development, which mostly are compile-once and run everywhere scenarios, device drivers are closely tied to the architecture of the system on which they will run. At an even lower level, device drivers may be specific to a particular type of kernel. The existence of multiple Linux OS implementations only exacerbates such issues.
It is desirable to provide software-based redundant array of independent disk (RAID) control solutions that support multiple enterprise options from multiple Linux vendors (e.g. Red Hat and Novell) for both 32-bit and 64-bit architectures. Currently, these variables translate into approximately 50 distinct kernels that must be supported for each release of a device driver.
It is advisable to compile device drivers in the environment where they are targeted to run. As such, in order to build a driver to be released for all supported kernels, multiple installations of these kernels would be required. Multiple installations require either physically distinct installations of each supported OS. Driver binaries can then be built in the native environment and then collected together over network in a centralized repository.
However, this would conceivably require dozen or more servers in order to compile the device drivers. Secondly, this solution is not easily scaleable. In event of a new supported OS, a new server installation would be required. This quickly makes it a very cost ineffective and high-maintenance solution. The IT costs associated with maintaining and backup the servers is also very cost-inhibitive.
The requirement of multiple build servers may be circumvented by installing one server per kernel architecture and implementing multi-booting (e.g. booting more than one OS on a given server). While such a configuration would solve the issue of cost and maintenance of multiple servers, it would drastically slowdown the driver build process because of multiple boot cycles required and would not translate to an automated build process.
As such, it would be desirable to provide a device driver compilation environment contained on a limited number of servers while avoiding the use of multi-booting.